Skip to content

Add Codex skills sync on release - #133

Merged
leenk7991 merged 2 commits into
mainfrom
feat/sync-skills-on-release
Jul 29, 2026
Merged

Add Codex skills sync on release#133
leenk7991 merged 2 commits into
mainfrom
feat/sync-skills-on-release

Conversation

@leenk7991

@leenk7991 leenk7991 commented Jul 27, 2026

Copy link
Copy Markdown
Member

What

Adds .github/workflows/sync-skills.yml: after a release ships, opens a PR against Corgea/skills updating the CLI skills to match what shipped.

Requires Documentation Update: - [ ] Yes - [x] No

Why release-triggered

Skills describe the CLI the reader already has installed. Diffing main would publish unreleased commands into a public skill, so the job diffs tag to tag.

Why not release.published

RELEASING.md documents two release paths, and that trigger only covers one. On the tag-first path the GitHub Release ends up created by action-gh-release using GITHUB_TOKEN, and GitHub does not start workflow runs for GITHUB_TOKEN events — so the sync would be silently skipped for a supported way of releasing.

This keys off the Native Binary Release workflow instead, which runs on the tag push under either path. npm-publish.yml already uses the same pattern. That payload carries no release object, so draft and prerelease filtering moved from the job condition into the script, and the tag comes from head_branch.

Notes

  • Whether a ref is a published release is resolved via the API, not a v-prefix match: history mixes v1.9.1 and 1.8.8, and a prefix match would skip the latter. Branch pushes, which also run Native Binary Release, resolve to no release and exit cleanly.
  • The previous release is resolved by publishedAt, not by excluding the current tag. Excluding the tag means a manual dispatch of an older tag selects a newer release as the base and produces a reversed diff, which reads as commands being removed.
  • queue: max on the concurrency group. The default holds one pending run, so three releases in quick succession would drop the middle one.
  • workflow_dispatch takes head_tag plus an optional base_tag. base_tag bypasses release lookup, so a plain tag with no Release can still be synced, and an explicitly named tag overrides draft filtering.
  • Reuses an existing repo secret, so there is nothing new to provision here.
  • No actions/checkout step: the action checks this repo out to ./source itself, and a root checkout would place skills/corgea/SKILL.md under the model's working directory as a decoy edit target.

Testing

workflow_run only fires from the default branch, so this cannot run until it is on main. The range-resolution logic was exercised against live release data: branch pushes skip, v1.9.2 resolves v1.9.1..v1.9.2, v1.9.1 correctly resolves v1.9.0 rather than the newer v1.9.2, 1.8.8 resolves v1.8.7, and a missing tag errors on dispatch but skips on workflow_run.

Merge order

Last, and strictly after Corgea/internal_actions#2 — the uses: reference resolves to main and 404s until that action lands.

Related: Corgea/internal_actions#2, Corgea/skills#2

Comment thread .github/workflows/sync-skills.yml Outdated
Comment thread .github/workflows/sync-skills.yml
Comment thread .github/workflows/sync-skills.yml
Comment thread .github/workflows/sync-skills.yml
release.published never fires for the tag-first path in RELEASING.md.
There the GitHub Release is created by action-gh-release using
GITHUB_TOKEN, and GitHub does not start workflow runs for GITHUB_TOKEN
events, so the sync was silently skipped for a supported release path.
Key off Native Binary Release instead, which runs on the tag push either
way; npm-publish.yml already uses this pattern.

The workflow_run payload has no release object, so draft and prerelease
filtering moves from the job-level condition into the script, and the
release tag is read from head_branch. Whether a ref is a published
release is resolved via the API rather than a v-prefix match, since tag
names are inconsistent (v1.9.1 but 1.8.8). Manual dispatch keeps its
existing semantics: base_tag still bypasses release lookup, and an
explicitly named tag still overrides draft filtering.

Also set queue: max. The default queue holds a single pending run, so
three releases published in quick succession would drop the middle one.

Co-authored-by: Cursor <cursoragent@cursor.com>

@yhoztak yhoztak left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

maybe good candidate for auto-approval? If so, please update this one also https://github.com/Corgea/doghouse/blob/main/.github/pr-automation-rules.yaml

@leenk7991
leenk7991 merged commit faa9eeb into main Jul 29, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants